Tl;dr: 

• Protocol direction clarified: Michael Sutton outlined a staged roadmap from Covenant++ toward zero-knowledge execution and verifiable programs (vProgs), framing long-term trade-offs between sovereignty, composability, and forward compatibility.

• PR Enhances Core infrastructure: Kaspa merged a pruning-proof optimization that lowers storage overhead and improves sync performance by reconstructing higher-level DAG relations on demand.

• New Approach To Oracles: Kaspa core researcher Eliott shared his first draft of a paper on oracles with a model for cross-exchange price discovery.

• Institutional settlement advanced: Kaspa Kii launched WarpCore (sandbox), positioning Kaspa as a deterministic settlement layer that bridges ISO 20022 financial messaging with public blockchain finality.

• Developer access expanded: New Python starter tooling reduced Kaspa application setup to roughly 30 seconds, while Testnet 12 covenants (KIP-17) were formally approved for Kaspathon projects.

KASmedia Analytics Charts

First, let’s get down to some selfish marketing business. KASmedia has begun publishing a new set of on-chain indicators, starting with the Kaspa Short-Term vs. Long-Term Holder Cost Basis Ratio (CBR). The chart compares realized prices between recent and long-term holders as a way to contextualize broader market regimes, which have historically aligned with bear, bull, and equilibrium phases.

The CBR is the first release in a planned series of Kaspa analytics charts that will be published over the coming weeks. Stay tuned for more! 

Michael Sutton Outlines Covenant++ ZK Milestones and Long-Term vProgs Direction

Kaspa core developer Michael Sutton shared a highly technical research note outlining a staged roadmap for extending Covenant++ toward zero-knowledge execution and, ultimately, full verifiable programs (vProgs) on Kaspa. The document reflects internal R&D discussion and long-term design exploration rather than a finalized implementation plan.

Sutton describes the purpose of the work as twofold: “to propose a gradual R&D process for extending the covenants++ hardfork to support zk systems,” while also exploring “the high-level trajectory towards the final vprogs design.” The notes build on existing covenant opcodes introduced in KIP-17, which enable protocol-enforced spending conditions on UTXOs, and zk verification primitives from KIP-16, which allow zero-knowledge proofs to be verified at the base layer.

In the short-to-mid term, the document focuses on sovereign standalone vProgs, beginning with an inline zk covenant milestone. In this model, zero-knowledge verification logic is embedded directly into covenant logic, meaning the protocol-enforced rules that the network checks before allowing a UTXO to be spent. This allows the network to verify zk proofs as part of transaction validation itself.

From there, the roadmap moves toward based zk covenants and a canonical bridge. In this stage, users no longer generate proofs themselves. Instead, specialized provers handle the heavy computation, while Kaspa’s base layer simply verifies the results. This allows many proofs to be combined and enables more advanced zero-knowledge applications. The trade-off, as Sutton notes, is reduced user sovereignty, since users rely on external provers rather than producing proofs independently.

The longer-term vision explores a path toward vProgs-based rollups and, eventually, full synchronous composability between sovereign programs. Sutton describes a central design trade-off: “the interim choice is between losing synchronous composability or losing sovereignty.” He adds that all intermediate milestones should be evaluated by how well they preserve forward compatibility with the final vProgs specification.

Kaspa Core PR Delivers Major Pruning-Proof Performance Gains

Kaspa core contributor @FreshAir08 shared an update on a merged pull request that significantly improves pruning-proof performance and overall node efficiency.

As FreshAir08 summarized it:

“TL;DR computing data relating to the pruning proof on the fly while building the proof rather than all the time results in substantial performance optimization on many fronts.”

Instead of continuously storing large amounts of metadata, the node now reconstructs only the small subset of relations needed when a pruning proof is built, meaning that when the node generates a compact proof, it can safely discard old blocks while preserving consensus security.

According to FreshAir08, the impact includes:

• Lower storage requirements, especially for archival nodes. 

• More efficient header processing by avoiding constant disk writes. 

• Faster initial block download (IBD). 

• Reduced pruning overhead, removing a major bottleneck on resource-constrained machines. 

Additional figures shared by @coderofstuff_ highlight the scale of the improvement:

• Header IBD reduced to under 2 hours, down from 4–6 hours. 

• Archival node storage (May 2024–Nov 2025) reduced from ~3.6 TB to ~1.4 TB after compaction. 

The change makes Kaspa nodes lighter, faster, and more scalable while preserving pruning and security guarantees, representing a meaningful improvement for long-running nodes and future network growth.

Eliott First Draft Oracle Paper

This is a big deal. As you know, KASmedia previously highlighted Oracle research by Elliott Mea. Over the weekend, he released a first draft of a new paper titled "A Mathematical Model for Cross-Exchange Price Discovery."

Ahead of release, Mea summarized the work as the best oracle in the industry, and as “a decentralized arbitrage network (DAN) that profits from CEX discrepancies, as well as secures the oracle (software that shall be distributed).” 

The paper proposes a no-arbitrage framework for computing an asset’s fair price by aggregating limit order books across multiple centralized exchanges into a single consolidated view. Rather than averaging reported prices, the model defines fair value as the price an asset would have “if all arbitrage were filled in an instant,” grounding price discovery explicitly in the mechanics of efficient markets.

The opening sections focus on how heterogeneous exchange order books can be embedded into a compatible price grid. This framing contrasts with many commonly used oracles, where users may see aggregated prices without clear visibility into data sources, weighting, or whether a single exchange dominates the signal. Mea’s approach treats price as a market outcome rather than an external input, with transparency and arbitrage closure as first principles.

To address latency, manipulation risk, and fragmented liquidity, the paper introduces a Decentralized Arbitrage Network (DAN). Exchanges are grouped into geographic or low-latency clusters, each of which is monitored by independent arbitrage agents. These agents work to eliminate local price discrepancies and filter out erroneous or manipulated prices. Within each cluster, small committees of aggregator nodes compute a consolidated local order book and derive a local fair price.

Cluster-level outputs are then propagated through Cluster Connectors to a small set of engine nodes, which recompute the global consolidated order book. This process is visualized in the paper through the Cross-Order-Book (COB) engine, which serves as the coordinating layer that enables prices to converge across regions without relying on a single trusted data source.

A central claim of the paper is that oracle robustness is achieved economically rather than procedurally. As arbitrage capital participating in the DAN increases, the cost of sustaining a price distortion rises sharply. As Mea notes, “the more the oracle secures, the more volume … is needed to counteract the potential attack incentive,” framing oracle security in terms of capital requirements rather than reputation or governance assumptions.

The motivation for this design reflects concerns Mea has raised publicly about structural inefficiencies in crypto markets. In a recent commentary, he argued that inefficiency is often revealed not by the speed of a crash, but by prolonged price discrepancies across centralized exchanges. During stress events, he observed that “price dislocations… lasted hours,” enabling unusually wide manual arbitrage spreads. In contrast, arbitrage gaps in traditional finance are typically closed in milliseconds due to concentrated venues, deep liquidity, and tightly integrated infrastructure. Crypto’s fragmented exchanges, withdrawal halts, API limits, and uneven liquidity can instead produce what he described as “visible but unactionable prices.”

Why this matters for crypto: Beyond any single chain or application, the paper speaks to a broader structural issue across the crypto ecosystem. Many protocols depend on oracle feeds whose sourcing, weighting, and manipulation costs are opaque to end users. By anchoring price discovery directly in no-arbitrage market mechanics and economic incentives, the framework reframes oracles as economic systems rather than trusted reporters. As on-chain activity becomes increasingly sensitive to short-lived price distortions, oracle models that internalize arbitrage pressure may become more relevant across the broader crypto stack.

For related analysis, see Eliott Mea’s examination of crypto market inefficiency during periods of stress and our interview article with Elliot, Eliott Méa: The Oracle Problem and The Kaspa Solution. 

Kaspa KII Launches WarpCore, Bridging ISO 20022 Messaging to Kaspa Finality

The Kaspa Industrial Initiative (Kaspa KII) announced the launch of WarpCore (Phase 1) in a sandbox environment for financial institutions. WarpCore is designed as an interoperability layer that connects ISO 20022 financial messaging standards to deterministic settlement logic on Kaspa. Kaspa KII summarized the system boundary succinctly as: “ISO 20022 In. Kaspa Finality Out.”

ISO 20022 is a global standard for financial messaging used by banks and payment systems to structure data for payments, settlements, securities, and reporting across institutions.

Rather than introducing a new payment rail, Kaspa KII emphasized WarpCore’s role as an adapter between existing institutional systems and public blockchain finality, stating: “This is not a new rail. It’s a translation layer.”

WarpCore allows banks to retain their current messaging formats, compliance controls, and operational pipelines while settling verifiable financial events on Kaspa’s proof-of-work base layer. As described in the launch materials: “Banks keep their existing messaging, controls, and compliance pipelines — while settling verifiable, immutable financial events on Kaspa.”

Privacy Coming to Kaspa, Introducing Kloak

Kaspa community member Olaf Weller shared a plain-language overview of Kloak, a privacy technique under development that focuses on transaction unlinkability rather than hiding balances or moving funds off-chain.

Weller emphasizes that Kloak does not obscure balances or custody, writing that it “changes how a transaction is constructed, not where the money ends up.” Funds remain fully visible on-chain, but the transaction structure itself is altered to prevent deterministic attribution.

In a standard Kaspa transaction, inputs typically come from a single sender, enabling chain analysis tools to infer payment flows and identify change outputs. With Kloak, both parties contribute inputs to the same transaction, producing multiple outputs and breaking common heuristics. As Weller explains, this results in “unlinkability, not invisibility.”

Kloak nodes act as “coordination endpoints, not mixers”. They do not hold funds or private keys, and wallets automatically coordinate with a node to construct joint transactions with minimal user interaction. Weller notes that the system “does not require protocol changes or vProgs,” and works on Kaspa’s current Layer-1, with wallet integration identified as the primary remaining step. 

KIP-17 Covenants: Early Security Patterns on Testnet 12

Kaspa community member CryptoPumpz shared an overview of security-focused use cases enabled by KIP-17 covenants, which are currently live on Kaspa Testnet 12.

Covenants are protocol-enforced spending rules attached directly to UTXOs, allowing the network itself to restrict future spending without introducing general-purpose smart contracts.

The post describes how covenants allow protocol-enforced spending conditions to be attached directly to Layer-1 UTXOs, without introducing general-purpose smart contracts. Examples discussed include address whitelisting, time-delayed spending, multi-signature requirements, and inactivity-based transfers for inheritance-style setups. These constraints can be combined, allowing multiple security rules to be enforced simultaneously at the protocol level.

While these features are still being tested on TN12 and are not yet available on mainnet, the discussion reflects growing community interest in using covenants to improve fund security and control while preserving Kaspa’s performance, proof-of-work security model, and decentralization guarantees.

Community Post Explains How Kaspa Mitigates Sandwich and MEV Attacks

In an educational post, Kaspa community member GoonBoyCrypto shared a walkthrough of how sandwich attacks and other forms of Maximal Extractable Value (MEV) affect users on account-based smart-contract platforms, using Ethereum as a reference point.

Describing a common scenario, he explains how users can receive less than expected on a swap even when the transaction succeeds, writing: 

“Your transaction sits between two others… Transaction #1: bot buys. Transaction #2: your swap. Transaction #3: bot sells. You just got sandwiched.” He characterizes this behavior as “an invisible tax on every DeFi participant.”

The post then contrasts this with Kaspa’s design. According to GoonBoyCrypto, Kaspa’s blockDAG architecture and GHOSTDAG consensus enable parallel block creation and rapid confirmations, thereby significantly reducing opportunities for transaction reordering. He notes that this limits front-running by MEV bots, helping preserve fairness, minimize fees, and avoid miner centralization.

While the post reflects community analysis rather than a protocol announcement, it provides a clear explanation of how Kaspa’s base-layer architecture addresses issues that have become structural on other networks.

Kaspa Python Starter Enables App Setup in ~30 Seconds

Kaspa community member IzioDev shared how developers can launch a Kaspa-integrated Python application in roughly 30 seconds using a new starter CLI. The tool bootstraps a working project with a single command and is built on the Kaspa Python SDK and an example API application developed by @smartgoo_.

The starter is designed to lower the barrier to entry for building on Kaspa. It supports a Python backend alongside optional React (frontend) and Node.js (server) components, enabling developers to experiment with event listeners, APIs, and application logic without spending time on initial configuration.

By simplifying setup and standardizing project structure, the tool makes it easier for new and experienced developers alike to prototype ideas, test integrations, and explore what Kaspa’s blockDAG architecture enables at the application layer. 

Kaspathon Reports Strong Early Participation

Kaspathon, a Kaspa-focused hackathon, reported that more than 160 developers have already registered, with one week remaining before the event begins.

The team also confirmed that Kaspa Testnet 12 covenants (KIP-17) are approved for use in hackathon projects. Participants may build against TN12 resources provided by Kaspa core developers, including access to a proof-of-concept covenant-enabled node.

The update reflects strong early builder interest and positions covenants as an available design surface for experimenting with new application patterns on Kaspa’s base layer during the event.

Kaspa Explorer Receives Incremental Improvements; TN12 Explorer Goes Live

Kaspa Explorer developer supertypo shared that a series of small improvements were implemented over the holiday period, many driven directly by community feedback.

In addition, a dedicated Testnet 12 explorer is now live, alongside a new network selector that allows users to switch between networks more easily. The update improves visibility into TN12 activity as covenant testing under KIP-17 continues in a public environment. 

KaspaBridge Smart Contracts Complete Third-Party Audit

Kaspa Finance announced that the smart contracts for KaspaBridge have successfully passed a third-party security audit conducted by RD Auditors. According to the audit report, findings were limited to low-severity and informational items, and the auditors concluded that the “system is suitable for production deployment.”

The completion of an external audit marks a key security milestone for KaspaBridge as it develops cross-chain infrastructure within the Kaspa DeFi ecosystem. Congrats Kaspa Finance! 

KaspaCom Adds Syndika Advisory Group as Strategic Advisor

KaspaCom announced that Syndika Advisory Group has joined as a strategic advisor.

According to the announcement, Syndika will support KaspaCom across fundraising and investor strategy, tokenomics, and preparation for the KCOM token generation event (TGE). Syndika described the engagement as focused on long-term execution, citing work “from tokenomics to the KCOM TGE.”

Syndika is a Web3 advisory and venture firm with experience across blockchain infrastructure, token economics, and ecosystem development, operating through advisory services, a venture studio, and a founder–builder network.

Kaspa Globe Previews Testnet 12 Network Visualization

Kaspa community member @p4bpj shared a screenshot preview of Kaspa Globe, a visualization tool that maps an approximation of the Kaspa network structure, with the preview highlighting Testnet 12 activity.

Kaspa Globe displays the geographical distribution of discovered Kaspa nodes on an interactive 3D globe, offering a visual snapshot of the network’s global presence and peer density. Because Kaspa is decentralized and peers cannot be exhaustively discovered, the visualization represents a sampled view rather than a complete network map.

The tool includes features such as peer search, network statistics, and support for both mainnet and testnet environments. While still in preview form, Kaspa Globe adds to a growing set of ecosystem tools aimed at improving transparency and observability across Kaspa’s rapidly scaling network.

Kurncy Wallet Previews NFC Payments on Kaspa

Kurncy shared an early demo of an NFC tap-to-pay flow settling directly on Kaspa Layer 1. Users can pay for items in a similar fashion to using Apple Pay. The demo uses a Kurncy Pass accessed via Apple Wallet or Google Wallet and is described as an experimental proof-of-concept rather than a production launch.

The team also released wallet version 1.1.97, adding optional biometric authentication.

U.S. Senate Banking Committee to Vote on Crypto Market Structure Bill

The U.S. Senate Committee on Banking, Housing, and Urban Affairs is scheduled to vote on a proposed crypto market structure bill on January 15, marking a procedural step toward clearer federal oversight of digital asset trading venues.

The legislation, commonly referred to as the CLARITY Act, would focus on market integrity measures, such as restrictions on wash trading, spoofing, and front-running, as well as expanded transparency requirements for U.S.-based exchanges, including proof-of-reserves and audit obligations. It would also enhance regulatory tools for monitoring market abuse.

While a committee vote does not guarantee passage into law, it represents a notable milestone in ongoing efforts to define oversight standards for crypto markets and reduce regulatory uncertainty.